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I. Real Party in Interest 

The real party in interest in this application is Metavante Corporation, the 
recorded assignee of the entire title of the subject application. 

II. Related Appeals and Interferences 

There are no other related appeals or interferences. 

III. Status of Claims 

Claims 2-10, 13, 17, 22-30, 32-34, 39, 41-43, 50 and 82-97 are pending in 
the case, and are all finally rejected. Claims 2-10, 13, 17, 22-30, 32-34, 39, 41-43, 
50 and 82-97 are being appealed, and a copy of these claims is attached hereto as 
the Claims Appendix. Claims 1, 11, 12, 14-16, 18-21, 31, 35-38, 40, 44-49, and 
51-81 have previously been cancelled. 

IV. Status of Amendments 

A July 18, 2005, amendment to the claims was the last amendment to be 
made to the claims, and was entered and considered. There was no post-final 
rejection amendment, leaving Claims 2-10, 13, 17, 22-30, 32-34, 39, 41-43, 50 and 
82-97 pending. 

V. Summary of Claimed Subject Matter 

Two independent claims are involved in this appeal: Claims 82 and 88. A 
concise explanation of the subject matter defined in each of these two independent 
claims will be described below, together with references to the specification of the 
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application as filed by page and line numbers, and to the drawings by reference 
numerals. 

Claim 82 . Claim 82 is directed to "[an] electronic bill presentment and 
payment system for presenting and paying bills via an electronic data network". 
An exemplary electronic bill presentment and payment platform in accordance 
with the present invention is 10 in Fig. 2, and is described in the specification from 
page 24, line 13 to page 32, line 13. The electronic data network is 21 in Fig. 2 
and is described in the application specification at page 24, lines 17-22. The 
claimed system has five (5) elements, each of which will be briefly discussed and 
references to the specification and drawings will be identified. 

Claim 82, element (a) . An input processing functionality adapted to 
receive billing data from a plurality of billers in a plurality of different billing data 
forms. Billers are 12 in Fig. 2. An input processing engine is 22 in Fig. 2 and is 
described in the application specification from page 25, line 12 to page 26, line 4, 
as having the functionality of receiving biller data 23 from billers 12 in any form 
or format provided by any biller 12. (See also page 25, line 1 through page 25 line 
1 1 of the application specification.) 

Claim 82, element (b) . A parsing functionality adapted to parse the 
billing data received from the plurality of billers in a plurality of different billing 
data forms to transform the billing data into a common document model wherein 
the transformed billing data is all of the same form. A rules based parsing engine 
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is 24 in Fig. 2 and is described in the application specification from page 26, line 5 
through page 28, line 2 as operating on or parsing a wide variety of biller data 
types and formats in order to fit a common document or data model. 

Claim 82, element (c) . A database adapted to store the transformed 
billing data parsed by the parsing functionality. The database is 26 in Fig. 2. The 
output from the parsing engine is stored in the database as described in the 
application specification at page 27, line 20 through page 28, line 2. 

Claim 82, element (d) . A presentation functionality coupled to the 
database and adapted to retrieve transformed billing data from the database and to 
output at least some of the retrieved transformed billing data via the electronic 
data network for use by bill payers. Bill payers are customers 18 in Fig. 2. 
Presentment processors are 42 and 44 in Fig. 6 and are described in the application 
specification at page 30, line 10 through page 32 line 13. The presentment 
processors communicate with the database 26 to retrieve data therefrom and 
present it in a desired manner to a customer 1 8 via the electronic data network 
(infrastructure 21) as described in the application specification at page 30, line 18 
through page 3 1 , line 1 1 . 

Claim 82, element (e) . Biller interactivity functionality coupled to 
the database and adapted to allow the plurality of billers individually to retrieve 
and review transformed billing data from the database and to alter the transformed 
billing data in the database. Presentment processors are 42 and 44 in Fig. 6 and 
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are described at page 30, line 10 through page 32 line 13 of the application 
specification. The platform 10 provides billers 12 with an interface to database 26 
and presentation processors 42 and 44 which enables billers to manage the 
administrative functions of electronic billing, including retrieving and reviewing 
billing data from the database and altering the data in the database in various ways 
as described in the application specification at page 31, line 12 through page 32, 
line 13. 

Claim 88 . Claim 88 is directed to "[a] method for presenting and paying 
bills via an electronic data network". A method in accordance with the present 
invention is illustrated in Fig. 3 and is described in the specification at page 28, 
lines 3-21. An exemplary system for performing the method in accordance with 
the present invention is 10 in Fig. 2, and is described in the specification from 
page 24, line 13 to page 32, line 13. The electronic data network is 21 in Fig. 2 
and is described in the application specification at page 24, lines 17-22. The 
claimed method has five (5) elements, each of which will be briefly discussed and 
references to the specification and drawings will be identified. 

Claim 88, element (a) . Receiving electronic billing data from a 
plurality of billers in a plurality of different billing data forms. Billers are 12 in 
Fig. 2. An input processing engine is 22 in Fig. 2 and is described in the 
application specification from page 25, line 12 to page 26, line 4, as having the 
functionality of receiving biller data 23 from billers 12 in any form or format 
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provided by any biller 12. (See also page 25, line 1 through page 25 line 1 1 of the 
application specification.) 

Claim 88, element (b) . Parsing in a computer the electronic billing 
data received from the plurality of billers in a plurality of different billing data 
forms to transform the billing data into a common document model wherein the 
transformed billing data is all of the same form. A rules based parsing engine is 
24 in Fig. 2 and is described in the application specification from page 26, line 5 
through page 28, line 2 as operating on or parsing a wide variety of biller data 
types and formats in order to fit a common document or data model. 

Claim 88, element (c) . A computer database adapted to store the 
transformed billing data parsed by the parsing functionality. The database is 26 in 
Fig. 2. The output from the parsing engine is stored in the database as described in 
the application specification at page 27, line 20 through page 28, line 2. 

Claim 88, element (d) . Retrieving transformed billing data from the 
database and outputting at least some of the retrieved transformed billing data via 
the electronic data network for use by bill payers. Bill payers are customers 18 in 
Fig. 2. Presentment processors are 42 and 44 in Fig. 6 and are described in the 
application specification at page 30, line 10 through page 32 line 13. The 
presentment processors communicate with the database 26 to retrieve data 
therefrom and present it in a desired manner to a customer 18 via the electronic 
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data network (infrastructure 21) as described in the application specification at 
page 30, line 18 through page 31, line 11. 

Claim 88, element (e) . Detecting and responding to electronic 
communications from the plurality of billers to allow the plurality of billers 
individually to retrieve and review transformed billing data from the database and 
to alter the transformed billing data in the database. Presentment processors are 42 
and 44 in Fig. 6 and are described in the application specification at page 30, line 
10 through page 32 line 13. The platform 10 provides billers 12 with an interface 
to database 26 and presentation processors 42 and 44 which enables billers to 
manage the administrative functions of electronic billing, including retrieving and 
reviewing billing data from the database and altering the data in the database in 
various ways as described in the application specification at page 31, line 12 
through page 32, line 13. 

Appellants regard as their invention a method and a system which are 
capable of automatically aggregating the bills of customers from a wide variety of 
different Internet-accessible sources at which the customers' bills are available 
irrespective of the implementation standards of the various sources of the billing 
information. Customers enter their access information for any of a wide variety of 
Internet accessible electronic bill sources at which the customers may access their 
bills into an interface. The present invention then uses a variety of software agents 
or "bots" to periodically access each of the Internet accessible bill sources using 
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the information provided by each of the customers to access and that customer's 
bills information, following which all of the bills are integrated into a single 
display of the customer's bills. The software agent programs used to obtain billing 
information from the Internet accessible bill sources obtains both bill summary 
information such as the account number, the statement date, the bill amount, the 
payment due date, the minimum amount, and the total amount due, but also 
obtains display information for each bill. This display information (the hypertext 
markup language that the biller sites use to display the bill) is processed by the 
software agent so that the billing information can be displayed by method and 
system of the present invention as a bill image which is essentially identical to the 
way it is displayed by the Internet accessible bill sources. Other features of the 
present invention include its ability to validate each customer's user ID and 
password, to give advance warning of any Internet accessible bill source problems 
prior to the payment initiation date, scheduling access to bills at predetermined 
times, assessing the validity of bill data, recognizing a change in Internet 
accessible bill source websites, as well as integrating bill data obtained from the 
Internet accessible bill sources with bill data received electronically from billers or 
even bill data obtained from paper bills. 
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VI. Grounds of Rejection to be Reviewed on Appeal 

Claims 2-10, 13, 17, 22-30, 32-34, 39, 41-43, 50 and 82-97 stand rejected 
under 35 U.S.C. § 102(e) as being anticipated by Savage et al. (U.S. Published 
Patent Application No. US 2002/0026394 Al). 

For the purposes of discussion herein, each independent claim (Claims 82 
and 88) will be argued separately, inasmuch as the invention of each such 
independent claim is separately and patentably distinguishable over the cited prior 
art. 

VII. Argument 

A. Summary of Arguments Presented on Appeal. 

Each of independent Claims 82 and 88 includes one or more 
elements, steps, and/or limitations which are not taught or suggested by the cited 
reference. Since Claims 82 and 88 each include elements, steps, and/or limitations 
which are not taught or suggested in the art, the rejection of independent Claims 
82 and 88 as being anticipated by the cited reference under 35 U.S.C. § 102(e) is 
incorrect and cannot be sustained for this reason. In the following sections of this 
Appeal Brief, this argument will be made with respect to each of independent 
Claims 82 and 88, pointing out the elements, steps, and/or limitations thereof that 
are not taught or suggested in the cited reference. 

B. Brief Discussion of the Reference Cited. 

Savage, et al describes a computer based system and method for combined 
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billing for a customer on a plurality of customer accounts. For example, credit 

card bills, utility bills, etc. may be combined in a single statement that is presented 

to a customer. A detailed presentation of the methods taught in Savage, et al is 

presented in Figs. 22 and 23 and paragraphs [0104]-[0110] thereof. As taught 

therein, a vendor (biller) creates and sends a flat file of vendor line items to a bill 

aggregator. The aggregator receives the files, verifies formatting of the line item, 

returns invalid items, and performs various checks and calculations on the data 

received. (Fig. 21 .) The data from the bill aggregator is used to render and deliver 

a bill to a customer, by paper invoice, electronic (web based) invoice, etc., for 

those customers who have requested a combined bill. 

C. Brief Overview of the Invention as Claimed and the Advantages 
Thereof 

The claims under appeal are drawn to a system and method that provides an 
adaptive and dynamic common document model for electronic bill presentment 
and payment in which a biller may maintain control over the biller's billing data 
after the data has been transformed from the format in which it was provided by 
the biller into a common document format 

The invention as claimed provides an electronic bill presentment and 
payment (EBPP) system and method which provides a common document model, 
allowing a plurality of billers to cooperatively present and accept payment of bills. 
The system and method as claimed parses the biller's data stream into a common 
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document model. The transformed data are stored in a database. The use of the 

common format document model and the universality of its structure allows the 

plurality of billers using the claimed system or method to maintain control, from a 

biller interactivity functionality, over their billing data and how it is presented on 

any desired platform using any desired applications, formats and protocols. In 

other words, the system and method as claimed can accommodate individual data 

sets from, for example, both a first and second biller without mandating a 

particular template (for the billers to follow) for both billers. Essentially, the 

common model document processing functionality as claimed provides for a 

generic conversion process that is not confined to a particular industry, biller, or 

type of customer. Thus, the invention as claimed provides for dynamic structural 

processing and conversion of a plurality of bill data types. 

Although Savage, et al. describes and suggests combining bills from 

various different billers into a combined billing statement, it is respectfully 

submitted that this reference does not describe in any detail how data presented in 

different form from different billers is to be handled. 

D. Arguments With Regard to the Rejection of Independent Claim 
82 and Claims 2-10, 13, 17, 39, 41-43, 50, 83-87, and 94-97 which 
Depend Therefrom. 

1. The Cited Reference Does Not Anticipate Claim 82. 

As discussed above, independent Claim 82 is drawn to a bill presentment 
and payment system adapted to receive billing data from a plurality of billers in a 
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plurality of different billing data forms, in which a parsing functionality is used to 
transform such billing data in different forms into a common document model 
wherein all of the billing data has the same form, wherein the transformed billing 
data is stored in a database and such transformed billing data is retrieved from the 
database to be output to bill payers, and in which the plurality of billers are 
allowed to retrieve, review, and alter the transformed billing data in the database. 

It is first respectfully submitted that it is well established that a claim is 
anticipated under 35 U.S.C. § 102(e) "only if each and every element that is set 
forth in the claim is found, either expressly or inherently described, in a single 
prior art reference". Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 
628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). "The identical invention must 
be shown in as complete detail as is contained in the . . . claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
For anticipation, there must be no difference between the claimed invention and 
the reference disclosure, as viewed by a person of ordinary skill in the field of the 
invention. Scripps Clinic & Res. Found, v. Genentech, Inc., 927 F.2d 1565, 18 
USPQ2d 1001 (Fed. Cir. 1991). In other words, the absence from the reference of 
any claimed element negates anticipation. Kloster Speedsteel AB v. Crucible, Inc., 
793 F.2d 1565, 230 USPQ 81 (Fed. Cir,. 1986). (See also MPEP 2131.) As will 
now be discussed in detail, there are at least three features or elements of Claim 
82, an input processing functionality, a parsing functionality, and a biller 
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interactivity functionality, that are not described or suggested in the cited 
reference. Therefore, Claim 82 is not anticipated by the cited reference under 35 
U.S.C. § 102(e). 

Independent Claim 82 features as an element thereof an input processing 
functionality adapted to receive billing data from a plurality of billers in a plurality 
of different billing data forms. It is respectfully submitted that this element of 
Claim 82 is not described or suggested in the cited reference. In contrast, the 
system and method of Savage, et al. appears to require that all billing data be 
received in the same flat file line item charge format. For example, Savage, et al. 
specifically states that line items received by the bill aggregator are verified for the 
proper form and returned if invalid. (See paragraph [0104] of Savage, et al. ) 

Independent Claims 82 further features as an element thereof a parsing 
functionality for handling billing data received from a plurality of billers in a 
plurality of different billing data forms, including parsing the data to transform the 
billing data into a common document model. It is respectfully submitted that 
Savage, et al. does not describe or suggest such a parsing functionality, since the 
system and method described in Savage, et al requires that all data be received in a 
pre-established flat file line item format. 

Independent Claim 82 also features a biller interactivity functionality 
wherein a biller is able to retrieve and review data after it has been received and 
transformed and alter the transformed billing data. It is respectfully submitted that 
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this feature is not described or suggested by the cited reference. Nothing in 

Savage, et al. describes or suggests that billers have the ability to retrieve and 

review data after it has been delivered to the bill aggregator described therein. 

2. Detailed Arguments with Respect to Examiner's Reasons 
for Rejecting Claim 82 

In the final Office Action of September 30, 2005, the Examiner cites Figs. 
1, 2, 3, 6, 8, 2.3 (there is no Fig. 2.3 in Savage et al„ so it will be assumed that Fig. 
23 was meant) , and 30 and paragraphs 0003, 0004, 0013, 0015, 0018, 0021, 0023, 
0054, 0055, and 0058 of Savage et al. as providing that teachings that anticipate 
each and every element of Claim 82. (The Examiner does not state which figures 
or paragraphs of Savage et al. are believed to correspond to which elements of 
Claim 82. Also, this same group of figures and paragraphs of Savage et al. is cited 
repeatedly by the examiner as providing the teachings for anticipation of all of the 
pending claims, both independent and dependant.) We will now look briefly at 
each of these figures and paragraphs of Savage et al. to examine what, in fact, they 
do teach, and to show that none of these figures or paragraphs teach of suggest the 
input processing functionality, parsing functionality, and biller interactivity 
functionality elements of Claim 82. 

Fig. 1 of Savage et al. shows a receivable management function that 
receives and aggregates billing data from a variety of communications, retail, 
energy, and financial billers. There is no suggestion that the billing data to be 
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aggregated is received from the billers in different billing data forms and is 
transformed into a common document model by the receivable management 
function. The receivable management function provides billing statements to 
customers, and provides customer service and remittance processing functions. 
There is no suggestion that the various billers themselves have any access to the 
billing data once it is sent to and aggregated by the receivable management 
function. 

Fig. 2 of Savage, et al. shows information flow between vendor and retail 
company billers, customers, and financial institution systems for generating 
combined billing statements. Information flow is shown as being two-way 
between each of these components. Once again, there is no suggestion that the 
information provided to the financial institution systems is received from the 
billers in different billing data forms and is transformed into a common document 
model by the financial institution systems. Also, there is no suggestion that the 
billers themselves have any access to billing information once it is sent to the 
financial institution system. 

Fig. 3 of Savage, et al. is a schematic diagram which illustrates the primary 
software modules for the system of combined billing being described. Note that 
none of the illustrated modules describe or suggest transforming billing data 
received from billers in different billing data forms into a common document 
model. Also, none of the illustrated software modules suggest that the billers 
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themselves have any access to billing information once it is processed by the 
system. 

Fig. 6 of Savage, et al. is a flow chart which provides further detail 
regarding the process of the customer making an inquiry in the system and method 
of combined billing being described. This flow chart does not mention billers and 
thus does not describe or suggest receiving billing data from billers in different 
billing data forms and transforming that data into a common document model. 
Also note that in the process being described the customer contact is with a 
customer service representative (CSR) that accesses databases associated with the 
combined billing system being described. The CSR may send a request to a 
Fulfillment System to send information to a customer resulting from a customer 
inquiry. There is no suggestion that the billers themselves have any access to the 
billing information in the combined billing system database. 

Fig. 8 of Savage et al. is a flow chart which provides further detail 
regarding the process of order entry or order capture for products and services for 
the customer in the system and method of combined billing being described. This 
shows a process that occurs between a customer and a CSR of the combined 
billing system. This flow chart does not mention billers and thus does not describe 
or suggest receiving billing data from billers in different billing data forms and 
transforming that data into a common document model. Nor is there any 
suggestion in the process illustrated that the billers themselves have any access to 
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the billing information in the combined billing system. 

Fig. 23 of Savage et al. is an illustration showing that billing for various 
products and services from different vendors (e.g., energy and communications 
vendors) can be bundled in the combined billing system being described and a 
discount applied to the customer bill for such bundled products and services. This 
illustration obviously does not describe or suggest receiving billing data from 
billers in different billing data forms and transforming that data into a common 
document model. Nor does it describe or suggest that the billers themselves have 
any access to the billing information in the combined billing system. 

Fig. 30 of Savage et al. is a chart depicting annual expenditures by industry. 
This chart also obviously does not describe or suggest receiving billing data from 
billers in different billing data forms and transforming that data into a common 
document model. Nor does it describe or suggest that billers themselves have any 
access to billing information in a combined billing system. 

Paragraph [0003] of Savage et al. reads as follows: 

[0003] Therefore, in order to make money, it is necessary for credit card 
providers to devise a way to lower infrastructure cost. A credit card 
provider has little control over its cost of financing. Therefore, the credit 
card provider must look at operating cost and endeavor to think creatively 
on how it can reduce such costs in order to give itself a strategic cost 
advantage. One possible way to reduce cost is to reduce the level of 
customer service, which would likely create dissatisfied customers. A far 
more attractive way to reduce cost is to leverage services over a bigger 
infrastructure, for example, by combining billing with multiple providers of 
goods and/or services. An attractive market to target is industries that 
provide recurring services, and statements, to the consumer. These are 
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industries such as telephony, insurance/annuities, cable/pay television, the 
energy markets (gas, water, and electricity), and home security. Service 
providers such as energy companies are shifting to a deregulated industry 
like that of the airline, financial and long distance telecommunications 
industries. Customers are able, or will be able, to choose from a wide 
variety of marketing entities which will provide their electricity. This 
choice encourages energy service companies to add value to their offering 
by lowering cost and developing new products and services and, in a sense, 
competing to be full home services provider. 

Paragraph [0004] of Savage et al. reads as follows: 

[0004] The electric and utility industries have annual revenues which 
exceed the yearly revenue of the long distance telecommunications industry 
and the local phone market, and these industries together have combined 
revenues that come close to rivaling the overall sum spent on all general 
purpose credit cards. Proposed deregulation includes, for example, the 
creation of non-profit corporations in charge of buying power from current 
monopoly power companies and for monitoring the transmission of power 
throughout a state, as well as the restructuring of utility companies to 
become local power distribution companies. In other words, under 
proposed deregulation, energy companies move away from vertical 
integration and divide the functions of generation (i.e., managing power 
plats to produce electricity); transmission (i.e., moving electricity from the 
power plant to the factory, office, or home); distribution (i.e. retailers 
marketing to the public); and marketing (i.e., selling electricity and the 
services associated with it to end users and maintaining the customer 
relationship). Similar to other deregulated industries, increased market 
competition and the ability for customers to select from multiple energy 
providers poses a great risk for energy companies, for example, in loss of 
share and increased losses. Deregulation opens opportunities for credit 
card providers, as well as for energy providers. Credit card providers 
increased overall card usage from 1 1% of all transaction in 1980 to 17% in 
1998. Utility payments provide another way of increasing that percentage. 

These two paragraphs describe challenges and opportunities for reducing costs in 

the credit card and utility industries. It is obvious that neither paragraph describes 

or suggests receiving billing data from billers in different billing data forms and 
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transforming that data into a common document model. Nor do these paragraphs 
describe or suggest that the billers themselves have any access to the billing 
information in a combined billing system. 

Paragraph [0013] of Savage et al. reads as follows: 

[0013] It is another feature and advantage of the present invention to 
provide a computerized method and system of combined billing which 
enables the billing of multiple product lines on a single statement, sharing 
the financial institution savings with the financial institution's clients and 
consumers, upselling customers of the financial institution's clients to 
become credit card customers, maximizing financing opportunities by 
purchasing receivables at a discount. 

This paragraph describes some features and advantages of the method and system 

of combined billing being described. Receiving billing data from billers in 

different billing data forms and transforming that data into a common document 

model are not described or suggested as features. Allowing billers themselves to 

have access to the billing information in the combined billing system is not 

described as a feature. 

Paragraph [0015] of Savage, et al. reads as follows: 

[0015] In an embodiment of the present invention, a financial 

institution, such as a bank, which issues credit cards, contracts with various 
companies to have all of their bill data delivered to the financial institution 
electronically. The financial institution stores the data at a customer level 
in its computer system. At the appropriate cycle time for a particular 
customer's account (i.e., the time at which the financial institution delivers a 
statement once a month to the customer), the financial institution's 
computer system automatically generates a combined statement and 
delivers it to the customer. When the financial institution receives the data 
electronically, for example, from the telephone company, it is stored in the 
financial institution's computer database. A single transaction is written out 
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to by the financial institution's account receivable computer system, 
sometimes referred to herein as "total systems." At different times in the 
month, the financial institution receives data electronically, for example, 
two or three different phone bills for a customer, which are reading out 
transaction one at a time to the financial institution's account receivable 
system. The financial institution can also be receiving, for the same 
customer, the customer's cable company, gas, water, and electric bill data, 
each reading out a transaction into the financial institution's account 
receivable system. When the account receivable system actually cycles, 
having accumulated the entire balance, any finance charge, late payment 
charge, or miscellaneous fees, computing the minimum payment amount 
and basically keeping the account in balance, the data image is forwarded to 
the financial institution from the financial institution's processing system, 
"total systems." The financial institution identifies each of those individual 
transaction that are read out and pulls them off of the statement and 
replaces them with the full image of the statement. Accordingly, the 
customer receives a complete branded statement for the customer's energy, 
water, gas, cable, and telephony, and a summary page with multiple 
payment options from which the customer can pay the account. 

This paragraph teaches that a financial institution receives billing data 

electronically from a variety of vendors in order to generate a combined billing 

statement for a customer. However, this paragraph does not describe or suggest 

that the billing data received from the various billers is received in different forms. 

Thus, the paragraph also does not describe or suggest transforming billing data 

received in a variety of different forms into a common document model. The 

paragraph also does not describe or suggest that the billers themselves have any 

access to the billing information once it is provided to the financial institution. 

Paragraph [0018] of Savage et al. reads as follows: 

[0018] The combined billing method and system of the present 
invention affords providers of goods and/or services the advantages of 
strategic cost savings and distribution opportunities. It also affords such 
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providers the ability to leverage off the financial institution's expertise in 
receivable management, marketing, billing, and multi-premise billing (e.g., 
combining multiple telephone statements that might otherwise go out at 
different times during the month from different premises into a single 
customer account). It also gives such providers the ability to integrate their 
own multiple accounts for a single customer with a single point-of-contact 
customer care number, so that when the customer calls, the financial 
institution understand exactly which account is meant. If a customer has, 
for example, telephone, energy and gas, and calls the financial institution 
about the telephone account, the customer is automatically routed into the 
telephony service provider for handling. In other words, the system is 
integrated to enable a consumer to reach a single point-of-contact and each 
individual provider of goods and/or services to continue their own customer 
care and servicing, while allowing the financial institution to handle the 
complex part of billing and data management. 

This paragraph discusses some of the advantages of the combined billing method 

and system being described, but does not describe or suggest that billing data 

received by a financial institution from various billers is received in different 

forms. Thus, the paragraph also does not describe or suggest transforming billing 

data received in a variety of different forms into a common document model. The 

paragraph also does not describe or suggest that the billers themselves have any 

access to the billing information once it is provided to the financial institution. 

Paragraph [0021] of Savage et al. reads as follows: 

[0021] In an embodiment of the present invention, the financial 

institution is able to increase its revenue through, for example, statementing 
savings of sharing or providing a service to the energy companies. The 
financial institution also increases revenue through financing with cost of 
funds and securitization at a lower cost than those of energy companies. 
Additionally, revenue is increased by customer servicing, namely, 
managing more efficiently than a utility via VRU technology. Further, the 
financial institution increases revenue by risk management in managing 
credit losses and fraud claims. The financial institution likewise increases 
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revenue in collections by managing collections more efficiently than a 
utility because of technology . Financial institution revenues are also 
increased by exporting bank rates, such as interest charges and fees on 
receivables that these companies might not be able to charge. In addition, 
financial institution revenues are increased through fee services related to 
marketing (acquisitions and portfolio) and information data mining. In 
order to satisfy all types of consumers, the financial institution furnishes 
management on various levels. For example, the financial institution 
performs billing management for a utility company in combination with a 
calling card, long distance and calling card, or long distance and calling 
card plus credit card. Consumers are incented to "add-on" to a single utility 
bill (i.e. with cash back or rewards points), while enjoying the convenience 
of having only one bill to pay. 

This paragraph describes various ways in which a financial institution may 

increase its revenue by operating a combined billing system as described. 

However, this paragraph does not describe or suggest that billing data received by 

the financial institution from various billers is received in different forms. Thus, 

the paragraph also does not describe or suggest transforming billing data received 

in a variety of different forms into a common document model. The paragraph 

also does not describe or suggest that the billers themselves have any access to the 

billing information once it is provided to the financial institution. 

Paragraph [0023] of Savage et al. reads as follows: 

[0023] In an embodiment of the present invention, one or more 

account charges are automatically formatted and transmitted to a bill 
aggregator, which aggregates the account charges. The account data from 
which the account charges are calculated includes usage data, such as 
energy usage data. The usage data is used to calculate usage charges 
according to a predefined usage pricing schedule, and the usage charges are 
used to calculate an associated usage tax according to a predefined usage 
charge tax schedule. The account charge is automatically calculated from 
the usage charge and the associated usage tax. When account data is 
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received by the financial institution computer application, it is 
automatically validated by comparing the data with pre-defined account 
data parameters, and data which falls outside the parameters is 
automatically rejected. Account charges are also automatically validated 
by comparing the account charges to predefined account charge parameters 
and rejecting charges which fall outside the predefined parameters. The 
account charges are aggregated by automatically assembling the charges 
and automatically calculating a discount for the assembled charges 
according to a predefined discount schedule. The aggregated account 
charges are calculated from the assembled account charges and the 
associated discount, and the aggregated account charges are likewise 
validated. 


This paragraph describes how, in an embodiment of the combined billing system 
being described, one or more account charges are automatically formatted and 
transmitted to a bill aggregator, which aggregates the account charges. As 
described, "formatting" in this case means employing usage data, such as energy 
usage data, received by a financial institution, along with a predefined usage 
pricing and tax schedule, to calculate the account charges. The resulting account 
charges are aggregated by automatically calculating a discount for the assembled 
charges according to a predefined discount schedule. Note that this paragraph 
does not describe or suggest that the usage data received by the financial 
institution may be received from various billers in different forms. Thus, the 
paragraph also does not describe or suggest transforming billing data received in a 
variety of different forms into a common document model. The paragraph also 
does not describe or suggest that the billers themselves have any access to the 
billing information once it is provided to the financial institution. 
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Paragraph [0054] of Savage et al. reads as follows: 

[0054] Referring now in detail to an embodiment of the invention, and 

example of which is illustrated in the accompanying drawings, FIG. 1 shows on 
[sic] overview of the key components for an application of the combined billing 
system for an embodiment of the present invention and the flow of information 
between the components. Referring to FIG. 1, the financial institution 100, such 
as a bank, is the entity which provides back office support for products and 
services, such as communications 102 (e.g., long distance 200, local 202, wireless 
204, and Internet 206); energy 104 (e.g., cable 208, home security 210, electric 
212, water 214, and gas 216); retail 106 (credit cards 218 and retail 220); and 
financial 108 (e.g., insurance 222, investments 224, auto 226, bank statements 
228, installments 230 and mortgages 232). The consumer or customer 110 is the 
person or entity, for example, at a terminal 112, such as a personal computer, who 
purchases the products and services that are offered and who is billed by the 
financial institution 100 and who remits payment to the financial institution 100. 
FIG.la presents a flow diagram of the combined application process. 


This paragraph describes the key components of the combined billing system 
being described, including a financial institution, various service providers 
(communications, energy, retail, and financial), and the consumer or customer. 
This paragraph does not describe or suggest that billing data is received by the 
financial institution from the various service providers in different forms. Thus, 
the paragraph also does not describe or suggest transforming billing data received 
in a variety of different forms into a common document model. The paragraph 
also does not describe or suggest that the billers themselves have any access to the 
billing information once it is provided to the financial institution. 


Paragraph [0055] of Savage et al. reads as follows: 

[0055] FIG. 2 is a simple schematic overview of key components for an 

application of an embodiment of the present invention, which provides further 
detail regarding the flow of information shown in FIG. 1. Referring to FIG. 2, 
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the "retail company" 234 is the entity which offers products and services to the 
retail market and is the client of the financial institution 100. In general, "supply 
chain vendors" 140 are the entities which provide the products and services that 
are offered for sale through retail company channels. Computer systems 114 of 
the financial institution 100 are configures to perform billing functions, such as 
bill calculation, bill aggregation and statementing, and payment processing. The 
financial institution's customer service representative (CSR) 101 is the person, for 
example, at the terminal 103, communicating with the customer 110 and the 
financial institution's computer systems 114. Bill calculation by computer 
systems 114 of financial institution 100 involves receiving and validating energy 
usage data feed, for example, from a vendor 140, such as energy retailer 104 
shown in FIG. 1, automatically calculating charges and taxes based on the energy 
pricing parameters of the energy retailer 104, and generating usage, accounting, 
and settlement reports to the energy retailer 104. Bill aggregation and statement 
by computer systems 114 involves automatically combining, for example, the 
energy 104, telecommunications 102 and credit card 106 statements, using the 
financial institution's credit card system interchange network to speed bundle 
offers to market, calculating bundled discounts, rebates and rewards, and 
automatically rendering a combined statement, such as paper, fax, web-based or 
disk to the customer 110. Payment processing by the financial institution's 
computer systems 114 is the processing of payment received from the customer 
110, for example, by check, autopay, or the Internet. 

This paragraph provides further detail regarding the flow of information between 

the components of the combined billing system being described. As described, 

computer systems of a financial institution are configured to perform billing 

functions, such as bill calculation, bill aggregation and statementing, and payment 

processing. Bill calculation involves receiving and validating energy usage data 

feed, for example, from a vendor, automatically calculating charges and taxes 

based on the energy pricing parameters of the energy retailer, and generating 

usage, accounting and settlement reports to the energy retailer. Bill aggregation 

and statementing involves automatically combining, for example, the energy, 

telecommunications, and credit card statements and automatically rendering a 
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combined statement. The paragraph does not describe or suggest that the billing 
data received by the financial institution from the various billers is received in 
different forms. Thus, the paragraph also does not describe or suggest 
transforming billing data received in a variety of different forms into a common 
document model. The paragraph also does not describe or suggest that the billers 
themselves have any access to the billing information once it is provided to the 
financial institution. In contrast, the biller only receives information back from 
the financial institution in the form of usage, accounting, and settlement reports. 
Paragraph [0058] of Savage et al. reads as follows: 

[0058] FIG. 3 is a schematic diagram which illustrates the primary 

software modules of computer systems 114 for an embodiment of the present 
invention and further amplifies the flow of information shown in FIGS. 1 and 2. 
The software modules of computer system 114 are coupled to one another and 
implemented, for example, to take orders, request services, and create invoices for 
the retail company. These modules include, for example, order entry 116, service 
contract 118, order processing 120, tracking system 122, and retail company bill 
aggregator 124. The order entry software modules 116 store and enable the 
customer service representatives (CSR) 101 to access data relative to all retail 
company customers 126, bundles 128, products 130, components 132, discounts 
134, orders 136, and affinity points 138. The service contract software module(s) 
118 track all appliance service contracts and service performed against these 
contracts. The order processing software module(s) 120 interface with the supply 
chain vendors 140 to request new service, modify existing service, or terminate 
service. The tracking system software module(s) 122 track all outstanding items 
that need to be resolved and notifies the CSR 101 of any exceptions that require 
attention. The retail company bill aggregator software module(s) 124 accepts 
charges from the supply chain vendors 140 and process these charges before 
forwarding the charges to the financial institution aggregator (CAP system) 142. 
The procession functions of the retail company bill aggregator software module(s) 
124 include charge validation 144, bill calculation for energy 146, discount 
calculation 148, and affinity point calculation. 

This paragraph describes various software modules of a computer system for 
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implementing the combined billing system being described. This paragraph does 
not describe or suggest that billing data is received from various billers in different 
forms. Thus, the paragraph does not describe or suggest a software module for 
transforming billing data received in a variety of different forms into a common 
document model. The paragraph also does not describe or suggest that the billers 
themselves have any access to the billing information once it is provided to the 
financial institution. Rather, that only information flow between the combined 
billing system and the supply chain vendors that is described is via an order 
processing software module, to request new service, modify existing service, or 
terminate service, or via a retail company bill aggregator software module that 
accepts charges from the supply chain vendors. 

Thus, it is submitted that none of the figures or paragraphs of Savage et al. 
that have been specifically cited by the Examiner as anticipating Claim 82, 
considered either separately or together, teach or suggest the elements of Claim 82 
of an input processing functionality adapted to receive billing data from a plurality 
of billers in a plurality of different billing data forms, a parsing functionality 
adapted to transform the billing data received in different forms into a common 
document model wherein the transformed billing data is all of the same form, and 
a biller interactivity functionality adapted to allow a plurality of billers 
individually to retrieve, review, and alter the transformed billing data. 
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3. Response to Examiner's Response to Arguments 

In the Response to Arguments section of the final Office Action in the 
Examiner states correctly that applicant/appellant essentially argues that the prior 
art fails to teach an inventive concept of receiving billing data from a plurality of 
billers in a plurality of different forms and parsing such data into a common 
document model wherein the transformed billing data is all the same form. The 
Examiner goes on to state: "Savage et al does not explicitly disclose that the 
received bills are in different format. However. It is obvious that the bills are not 
from the same company and therefore in different format since each company uses 
their own format to prepare customer invoice. For the reason above, the rejection 
is sustained." 

Applicant strongly disagrees with the Examiner's conclusions regarding the 
teachings of Savage et al. First, the Examiner admits that the cited reference does 
not expressly describe or suggest receiving billing data in different formats. There 
is no reason to assume that the system described in the cited reference is 
inherently adapted to receive billing data in different billing data forms. It is more 
reasonable to assume that the system described in the cited reference requires the 
various billers using the system to format billing data in a format that is acceptable 
to the system. In fact, Savage et al. suggests that billing data is received by the 
system as a flat file of vendor line item charges and that items are returned as 
invalid if this format is not adhered to. (See paragraph [0104] of Savage et al. ) 
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Furthermore, neither the term, nor the concept, of a "common document model", 
as featured in Claim 82, is mentioned in Savage et al. Additionally, although 
different companies may use their own format to prepare customer invoices, it is 
not customer invoices that are provided by the companies to the system described 
in Savage et al. Rather, underlying billing data, e.g., energy usage data, is 
provided (see paragraph [0055] of Savage et al. ) and from this data a combined 
billing statement is generated by the system having a format defined by the 
combined billing system, not by the biller. (See paragraph [0110] of Savage et al. ) 

As discussed above, another element of Claim 82 that is not taught or 
suggested by Savage et al. is the biller interactivity functionality adapted to allow 
a plurality of billers individually to retrieve, review, and alter transformed billing 
data. This element of Claim 82 is not mentioned in the Examiner's Response to 
Arguments. 

4. Conclusion with Regard to Claim 82 

Thus, it is respectfully submitted that the cited reference does not describe 
or suggest an input processing functionality for receiving billing data from a 
plurality of billers in a plurality of different billing data forms, and thus does not 
describe or suggest a parsing functionality adapted to parse such data into a 
common document model wherein the transformed billing data is all of the same 
form. It is also respectfully submitted that the cited reference and does not 
describe or suggest a biller interactivity functionality allowing a biller the ability 
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to retrieve and review such transformed billing data. Each of these features is an 
element of pending independent Claims 82. Therefore, it is respectfully submitted 
that independent claim 82, as well as the claims that depend therefrom, is not 
anticipated by the cited reference, and are in condition for allowance, for the 
foregoing reasons. 

E. Arguments With Regard to the Rejection of Independent Claim 
88 and Claims 22-30, 32-34, and 89-93 Which Depend 
Therefrom 

1. The Cited Reference Does Not Anticipate Claim 88 

As discussed above, independent Claim 88 is drawn to a method for 
presenting and paying bills that includes the steps of receiving electronic billing 
data from a plurality of billers in a plurality of different billing data forms, parsing 
in a computer the received electronic billing data to transform such billing data in 
different forms into a common document model wherein all of the billing data has 
the same form, wherein the transformed billing data is stored in a database, 
retrieving the transformed billing data from the database to be output to bill 
payers, and in which electronic communications from the plurality of billers are 
detected and responded to to allow the plurality of billers to retrieve, review, and 
alter the transformed billing data in the database. 

It is first respectfully submitted that it is well established that a claim is 
anticipated under 35 U.S.C. § 102(e) "only if each and every element that is set 
forth in the claim is found, either expressly or inherently described, in a single 
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prior art reference". Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 
628, 2 USPQ2d 1051, 1053 (Fed. Cir. 1877). "The identical invention must be 
shown in as complete detail as is contained in the . . . claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
For anticipation, there must be no difference between the claimed invention and 
the reference disclosure, as viewed by a person of ordinary skill in the field of the 
invention. Scripps Clinic & Res. Found, v. Genentech, Inc., 927 F.2d 1565, 18 
USPQ2d 1001 (Fed. Cir. 1991). In other words, the absence from the reference of 
any claimed element negates anticipation. Kloster SpeedsteelAB v. Crucible, Inc., 
793 F.2d 1565, 230 USPQ 81 (Fed. Cir,. 1986). (See also MPEP 2131.) As will 
now be discussed in detail, there are at least three features or steps of Claim 88, a 
receiving step, a parsing step, and a step of detecting and responding to electronic 
communications from a plurality of billers, that are not described or suggested in 
the cited reference. Therefore, Claim 88 is not anticipated by the cited reference 
under 35 U.S.C. § 102(e). 

Independent Claim 88 features as an element thereof a receiving step of 
receiving billing data from a plurality of billers in a plurality of different billing 
data forms. It is respectfully submitted that this element of Claim 88 is not 
described or suggested in the cited reference. In contrast, the system and method 
of Savage, et al. appears to require that all billing data be received in the same flat 
file line item charge format. For example, Savage, et al. specifically states that 
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line items received by the bill aggregator are verified for the proper form and 
returned if invalid. (See paragraph [0104] of Savage, et al. ) 

Independent Claims 88 further features as an element thereof a parsing step 
for handling billing data received from a plurality of billers in a plurality of 
different billing data forms, including parsing the data to transform the billing data 
into a common document model. It is respectfully submitted that Savage, et al. 
does not describe or suggest such a parsing step, since the system and method 
described in Savage, et al requires that all data be received in a pre-established flat 
file line item format. 

Independent Claim 88 also features the step of detecting and responding to 

electronic communications from a plurality of billers to allow billers individually 

to retrieve and review data after it has been received and transformed and to alter 

the transformed billing data. It is respectfully submitted that this feature is not 

described or suggested by the cited reference. Nothing in Savage, et al. describes 

or suggests that billers have the ability to retrieve and review data after it has been 

delivered to the bill aggregator described therein. 

2. Detailed Arguments with Respect to Examiner's Reasons 
for Rejecting Claim 88. 

In the final Office Action of September 30, 2005, the Examiner cites Figs. 

1, 2, 3, 6, 8, 2.3 (there is no Fig. 2.3 in Savage et al„ so it will be assumed that Fig. 

23 was meant) , and 30 and paragraphs 0003, 0004, 0013, 0015, 0018, 0021, 0023, 
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0054, 0055, and 0058 of Savage et al. as providing that teachings that anticipate 
each and every element of Claim 88. (The Examiner does not state which figures 
or paragraphs of Savage et al. are believed to correspond to which elements of 
Claim 88. Also, this same group of figures and paragraphs of Savage et al. is cited 
repeatedly by the examiner as providing the teachings for anticipation of all of the 
pending claims, both independent and dependant.) 

Provided above, in the discussion with respect to Claim 82, is a brief 
examination of each of these figures and paragraphs of Savage et al. examining 
what, in fact, they do teach. As was shown above, none of these figures or 
paragraphs teach of suggest the input processing functionality, parsing 
functionality, and biller interactivity functionality elements of Claim 82. 

It can be seen from a review of the discussion of these figures and 
paragraphs, as presented above, that none of the figures or paragraphs of Savage et 
al. that have been specifically cited by the Examiner as anticipating Claim 88, 
considered either separately or together, teach or suggest the elements of Claim 88 
of receiving billing data from a plurality of billers in a plurality of different billing 
data forms, parsing the billing data to transform the billing data received in 
different forms into a common document model wherein the transformed billing 
data is all of the same form, and detecting and responding to electronic 
communications from a plurality of billers to allow billers individually to retrieve, 
review, and alter the transformed billing data. 
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3. Response to Examiner's Response to Arguments. 

In the Response to Arguments section of the final Office Action in the 
Examiner states correctly that applicant/appellant essentially argues that the prior 
art fails to teach an inventive concept of receiving billing data from a plurality of 
billers in a plurality of different forms and parsing such data into a common 
document model wherein the transformed billing data is all the same form. The 
Examiner goes on to state: "Savage et al does not explicitly disclose that the 
received bills are in different format. However. It is obvious that the bills are not 
from the same company and therefore in different format since each company uses 
their own format to prepare customer invoice. For the reason above, the rejection 
is sustained." 

Applicant strongly disagrees with the Examiner's conclusions regarding the 
teachings of Savage et al. First, the Examiner admits that the cited reference does 
not expressly describe or suggest receiving billing data in different formats. There 
is no reason to assume that the system described in the cited reference is 
inherently adapted to receive billing data in different billing data forms. It is more 
reasonable to assume that the system described in the cited reference requires the 
various billers using the system to format billing data in a format that is acceptable 
to the system. In fact, Savage et al. suggests that billing data is received by the 
system as a flat file of vendor line item charges and that items are returned as 
invalid if this format is not adhered to. (See paragraph [0104] of Savage et al. ) 
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Furthermore, neither the term, nor the concept, of a "common document model", 
as featured in Claim 82, is mentioned in Savage et al. Additionally, although 
different companies may use their own format to prepare customer invoices, it is 
not customer invoices that are provided by the companies to the system described 
in Savage et al. Rather, underlying billing data, e.g., energy usage data, is 
provided (see paragraph [0055] of Savage et al. ) and from this data a combined 
billing statement is generated by the system having a format defined by the 
combined billing system, not by the biller. (See paragraph [0110] of Savage et al. ) 

As discussed above, another step or element of Claim 88 that is not taught 
or suggested by Savage et al. is detecting and responding to electronic 
communications from a plurality of billers to allow the plurality of billers 
individually to retrieve, review, and alter transformed billing data. This element 
of Claim 88 is not mentioned in the Examiner's Response to Arguments. 
4. Conclusion with Regard to Claim 88 

Thus, it is respectfully submitted that the cited reference does not describe 
or suggest receiving billing data from a plurality of billers in a plurality of 
different billing data forms, and thus does not describe or suggest parsing such 
data into a common document model wherein the transformed billing data is all of 
the same form. It is also respectfully submitted that the cited reference does not 
describe or suggest detecting and responding to electronic communications from a 
plurality of billers to allow the billers individually to retrieve and review such 
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transformed billing data. Each of these features is an element of pending 
independent Claim 88. Therefore, it is respectfully submitted that independent 
claim 88, as well as the claims that depend therefrom, is not anticipated by the 
cited reference, and are in condition for allowance, for the foregoing reasons. 

E. Additional Arguments for the Allowability of Dependent Claims 
85, 91, 95, and 97. 

1. Dependent Claims 85 and 91. 

Dependent claims 85 and 91, which depend, indirectly, from independent 
claims 82 and 88, respectively, feature parsing the billing data received from a 
plurality of different billers in a plurality of different forms using rules of 
conversion defined using a uniform rules definition language. (See, e.g., the 
application specification at pages 26 and 27.) It is respectfully submitted that 
Savage, et al does not describe or suggest a rules based process defined using a 
uniform rules definition process to parse biller billing data in a plurality of 
different forms. 

As discussed above, Savage, et al . does not teach or suggest receiving data 
in a plurality of different billing data forms, and thus does not describe or suggest 
the parsing functionality, and thus does not teach or suggest rules of conversion 
defined using a uniform rules definition language. 

2. Dependent Claim 95. 

Dependent Claim 95 further distinguishes over Savage, et al. by reciting a 
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biller interactivity functionality coupled to the database adapted to allow the 
plurality of billers to identify market segments of said bill payers according to 
market rules and information retrieved from said database. There is no mention of 
the billers being able to identify market segments of bill payers in the Savage, et 
al Rather, Savage, et al. suggests that retrieving marketing information from a 
database of billing data may be a service that is provided by the financial 
institution acting as the bill aggregator. Savage, et al. does not describe or suggest 
that the billers may have access to such data. Thus, it is respectfully submitted 
that claim 95 and the claims that depend therefrom are allowable over the cited 
references for this additional reason. 
3. Dependent Claim 97. 

No evidence is provided for the anticipation, teaching, or suggestion of a 
modularized input processing engine, as recited in dependent Claim 97. The 
advantage of using a modularized processing engine is that this facilitates 
scalability and expandability. For example, if a new form of biller data is 
encountered or must be dealt with for transformation into a form and format, the 
modularized input processing engine of Claim 97 allows for the processing of the 
new biller data in a modular way (see Applicants' Specification, page 25, lines 17- 
19). There may be separate engines for each new form of data so that the output 
of each preprocessing engine is ready for processing by a rule-based parsing 
engine. In other words, because the preprocessing of biller data is modularized, a 
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new input processing engine can easily be integrated to handle new data types. 
Therefore, Claim 97 is believed to be patentable for the additional reasons 
provided. 
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F. Conclusion. 

The independent claims of the present application are drafted in a manner 
which clearly defines them over the prior art. Accordingly, Appellants believe the 
invention as presently claimed to be novel and non-obvious over the cited art. 
Appellants accordingly respectfully request the removal of all rejections of the 
pending Claims 2-10, 13, 17, 22-30, 32-34, 39, 41-43, 50 and 82-97. 
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Kevin L. Wingate 
Attorney for Appellants 
Registration No. 38662 


Date: January 4, 2008 

Reinhart Boerner Van Deuren P.C. 
2215 Perrygreen Way 
Rockford, Illinois 61107 


Customer No. 53609 


Application No. 09/543,938 


Page 41 


VIII. Claims Appendix 

1. (cancelled) 

2. (previously presented): The system according to Claim 82, wherein said parsing 
functionality is adapted to parse data from a print stream of data provided by said 
plurality of billers. 

3. (previously presented): The system according to Claim 82, wherein said parsing 
functionality is adapted to parse data from a data interchange stream of data provided 
by said plurality of billers. 

4. (previously presented): The system according to Claim 82, wherein said parsing 
functionality is adapted to parse data from a financial data stream provided by said 
plurality of billers. 

5. (previously presented): The system according to Claim 82, wherein said 
presentation functionality is adapted to output transformed billing data for use by said 
bill payers using financial software. 

6. (previously presented): The system according to Claim 82, wherein said 
presentation functionality is adapted to output transformed billing data for use by said 
bill payers not using financial software. 

7. (previously presented): The system according to Claim 82, wherein said 
presentation functionality is adapted to output transformed billing_data for use by said 
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bill payers using a browser. 

8. (previously presented): The system according to Claim 82, wherein said 
presentation functionality employs style sheet functionality in order to render 
transformed billing_data in a form suitable for said bill payers. 

9. (previously presented): The system according to Claim 82, wherein transformed 
billing data is provided to said bill payers using markup language. 

10. (previously presented): The system according to Claim 82, further comprising an 
interactivity functionality adapted to detect and respond to communications from said 
bill payers by at least (i) retrieving transformed billing_data from said database and 
presenting it to said bill payers in a form requested by said bill payers; and (ii) 
altering transformed billing data in said database corresponding to said bill payers 
according to said communications. 

11-12. (cancelled) 

13. (previously presented): The system according to Claim 82, wherein the biller 
interactivity functionality is adapted to allow said plurality of billers to alter 
appearance and content of bills presented to said bill payers, said biller interface 
allowing said plurality of billers to communicate with said bill payers regarding said 
bills. 

14-16. (cancelled) 

17. (previously presented): The system according to Claim 87, wherein the third 
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party interactivity functionality is a financial source interface adapted to send and 
receive communications to and from at least one financial entity and to alter the 
transformed billing data in said database according to said financial source 
communications. 

18-21. (cancelled) 

22. (previously presented): The method of Claim 88, wherein said billing data is 
received as a print stream of data provided by said plurality of billers. 

23. (previously presented): The method of claim 88, wherein said billing data is 
received as a data interchange stream of data provided by said plurality of billers. 

24. (previously presented): The method of Claim 88, wherein said billing data is 
received as a financial data stream provided by said plurality of billers. 

25. (previously presented): The method of Claim 88, wherein said at least some of 
said transformed billing data is output for use by said bill payers using financial 
software. 

26. (previously presented): The method of Claim 88, wherein said at least some of 
said transformed billing data is output for use by said bill payers not using financial 
software. 

27. (previously presented): The method of Claim 88, wherein said at least some of 
said transformed billing data is output for use by said bill payers using a browser. 

28. (previously presented): The method of Claim 88, wherein said at least some of 
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said transformed billing data is output using style sheet functionality in order to 
render information in a form suitable for said bill payers. 

29. (previously presented): The method of Claim 88, wherein said at least some of 
said transformed billing data is provided to said bill payers using markup language. 

30. (previously presented): The method of Claim 88, further comprising the step of 
detecting and responding to communications from bill payers by at least (i) retrieving 
transformed billing data from said database and presenting it to said bill payers in a 
form requested by said bill payers and (ii) altering transformed billing data in said 
database corresponding to said bill payers according to said communications. 

31. (cancelled) 

32. (previously presented): The method of Claim 88, further comprising the step of 
allowing said plurality of billers to alter appearance and content of bills presented to 
said bill payers. 

33. (previously presented): The method of Claim 88, further comprising the step of 
allowing said plurality of billers to communicate with said bill payers regarding said 
bills. 

34. (previously presented): The method of Claim 93, wherein detecting and 
responding to communications to and from a third party included detecting and 
responding to communication from at least one financial entity and altering and 
storing information according to said communications. 
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35-38. (canceled) 

39. (previously presented): The system of Claim 94, wherein said interface is 
adapted to allow said bill payers to specify the location of said output. 

40. (cancelled) 

41. (previously presented): A system according to Claim 95, wherein said biller 
interactivity functionality is further adapted to allow said plurality of billers to alter 
appearance and content of bills presented to said bill payers based on said market 
segments. 

42. (previously presented): A system according to Claim 95, wherein said biller 
interactivity functionality is further adapted to allow said plurality of billers to send 
marketing messages to said bill payers based on said market segments. 

43. (previously presented): A system according to Claim 95, wherein said biller 
interactivity functionality is further adapted to allow said plurality of billers to 
communicate with said bill payers based on said market segments. 

44-49. (cancelled) 

50. (previously presented): A system according to Claim 82, wherein said biller 
interactivity functionality and said presentation functionality are further adapted to 
present substantially the same information to said plurality of billers and said bill 
payers in order to allow said plurality of billers to interact with said bill payers 
regarding said same information. 

51-81. (cancelled) 


Page 46 

82. (previously presented): An electronic bill presentment and payment system for 
presenting and paying bills via an electronic data network, comprising: 

(a) an input processing functionality adapted to receive billing data from a 
plurality of billers in a plurality of different billing data forms; 

(b) a parsing functionality adapted to parse the billing data received from the 
plurality of billers in a plurality of different billing data forms to transform the billing 
data into a common document model wherein the transformed billing data is all of the 
same form; 

(c) a database adapted to store the transformed billing data parsed by the parsing 
functionality; 

(d) presentation functionality coupled to the database and adapted to retrieve 
transformed billing data from the database and to output at least some of the retrieved 
transformed billing data via the electronic data network for use by bill payers; and 

(e) biller interactivity functionality coupled to the database and adapted to allow 
the plurality of billers individually to retrieve and review transformed billing data 
from the database and to alter the transformed billing data in the database. 

83. (previously presented) The system according to Claim 82 wherein the electronic 
data network is the Internet. 

84. (previously presented): The system according to Claim 82 wherein the parsing 
functionality is adapted to parse the billing data received from the plurality of billers 
to transform the billing data into a common document model using rules of 
conversion and a rules application process. 
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85. (previously presented): The system according to Claim 84 wherein the rules of 
conversion are defined by an operator using a uniform rules definition language. 

86. (previously presented): The system according to Claim 82 wherein the common 
document model is adapted to accommodate the transformed billing data from the 
plurality of billers and wherein each of the plurality of billers has a subset of data and 
attributes accommodated by the common document model. 

87. (previously presented): The system according to Claim 82 comprising 
additionally a third party interactivity functionality coupled to the database and 
adapted to allow a third party to retrieve for review transformed billing data from the 
database and to alter the transformed billing data in the database. 

88. (previously presented): A method for presenting and paying bills via an 
electronic data network, comprising: 

(a) receiving electronic billing data from a plurality of billers in a plurality of 
different billing data forms; 

(b) parsing in a computer the electronic billing data received from the plurality of 
billers in a plurality of different billing data forms to transform the billing data into a 
common document model wherein the transformed billing data is all of the same 
form; 

(c) a computer database adapted to store the transformed billing data parsed by the 
parsing functionality; 

(d) retrieving transformed billing data from the database and outputing at least 
some of the retrieved transformed billing data via the electronic data network for use 
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by bill payers; and 

(e) detecting and responding to electronic communications from the plurality of 
billers to allow the plurality of billers individually to retrieve and review transformed 
billing data from the database and to alter the transformed billing data in the database. 

89. (previously presented): The method according to Claim 88 wherein the 
electronic data network is the Internet. 

90. (previously presented): The method according to Claim 88 wherein the parsing 
the billing data received from the plurality of billers to transform the billing data into 
a common document model includes parsing the billing data in a computer using rules 
of conversion and a rules application process. 

91. (previously presented): The method according to Claim 90 comprising 
additionally defining the rules of conversion using a uniform rules definition 
language. 

92. (previously presented): The method according to Claim 88 wherein the common 
document model is adapted to accommodate the transformed billing data from the 
plurality of billers and wherein each of the plurality of billers has a subset of data and 
attributes accommodated by the common document model. 

93. (previously presented): The method according to Claim 88 comprising 
additionally detecting and responding to communications from a third party to allow 
the third party to retrieve for review transformed billing data from the database and to 
alter the transformed billing data in the database. 
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94. (previously presented): The system according to Claim 82 comprising 
additionally a bill payer interface adapted to allow said bill payers to pay bills 
electronically. 

95. (previously presented): The system according to Claim 82 wherein the biller 
interactivity functionality allows said plurality of billers to identify market segments 
of said bill payers according to market rules and information retrieved from said 
database. 

96. (previously presented): The system according to Claim 87 wherein the third 
party interactivity functionality includes an agent interface coupled to the database 
and adapted to allow a plurality of agents having agency relationships with said 
plurality of billers to communicate with said bill payers regarding bills. 

97. (previously presented): The system according to Claim 82 wherein the input 
processing functionality includes a modularized input processing engine adapted to 
preprocess billing data corresponding to a plurality of data types from the plurality of 
billers and providing the preprocessed billing data to the parsing functionality for 
parsing. 
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IX. Evidence Appendix 


None 
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X. Related Proceedings Appendix 


None 


